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Abstract 


RFC 1591, "Domain Name System Structure and Delegation", laid out the 
basic administrative design and principles for the allocation and 
administration of domains, from the top level down. It was written 
before the introduction of the world wide web (WWW) and rapid growth 
of the Internet put significant market, social, and political 
pressure on domain name allocations. In recent years, 1591 has been 
cited by all sides in various debates, and attempts have been made by 
various bodies to update it or adjust its provisions, sometimes under 
pressures that have arguably produced policies that are less well 
thought out than the original. Some of those efforts have begun from 
misconceptions about the provisions of 1591 or the motivation for 
those provisions. The current directions of the Internet Corporation 
for Assigned Names and Numbers (ICANN) and other groups who now 
determine the Domain Name System (DNS) policy directions appear to be 
drifting away from the policies and philosophy of 1591. This 
document is being published primarily for historical context and 
comparative purposes, essentially to document some thoughts about how 
1591 might have been interpreted and adjusted by the Internet 
Assigned Numbers Authority (IANA) and ICANN to better reflect today’s 
world while retaining characteristics and policies that have proven 
to be effective in supporting Internet growth and stability. An 
earlier variation of this memo was submitted to ICANN as a comment on 
its evolving Top-level Domain (TLD) policies. 
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Le 


Introduction 


RFC 1591 [1] has been heavily discussed and referenced in the last 
year or two, especially in discussions within ICANN and its 
predecessors about the creation, delegation, and management of top- 
level domains. In particular, the ICANN Domain Name Supporting 
Organization (DNSO), and especially its ccTLD constituency, have been 
the home of many discussions in which 1591 and interpretations of it 
have been cited in support of a variety of sometimes-contradictory 
positions. During that period, other discussions have gone on to try 
to reconstruct the thinking that went into RFC 1591. Those in turn 
have led me and others to muse on how that original thinking might 
relate to some of the issues being raised. 1591 is, I believe, one 
of Jon Postel’s masterpieces, drawing together very different 
philosophies (e.g., his traditional view that people are basically 
reasonable and will do the right thing if told what it is with some 
stronger mechanisms when that model is not successful) into a single 
whole. 


RFC 1591 was written in the context of the assumption that what it 
described as generic TLDs would be bound to policies and categories 


of registration (see the "This domain is intended..." text in 
section 2) while ccTLDs were expected to be used primarily to support 
users and uses within and for a country and its residents. The 
notion that different domains would be run in different ways --albeit 
within the broad contexts of "public service on behalf of the 
Internet community" and "trustee... for the global Internet 
community"-- was considered a design feature and a safeguard against 
a variety of potential abuses. Obviously the world has changed in 
many ways in the seven or eight years since 1591 was written. In 


particular, the Internet has become more heavily used and, because 
the design of the world wide web has put domain names in front of 
users, top-level domain names and registrations in them have been 
heavily in demand: not only has the number of hosts increased 
dramatically during that time, but the ratio between registered 
domain names and physical hosts has increased very significantly. 


The issues 1591 attempted to address when it was written and those we 
face today have not changed significantly in principle. But one 
alternative to present trends would be to take a step back to refine 
it into a model that can function effectively today. Therefore, it 
may be useful to try to reconstruct 1591’s principles and think about 
their applicability today as a model that could continue to be 
applied: not because it is historically significant, but because many 
of its elements have proven to work reasonably well, even in 


difficult situations. In particular, for many domains (some in 
1591’s "generic" list and others in its "country code" category) the 
notion of "public service" --expected then to imply being carried out 
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at no or minimal cost to the users, not merely on a non-profit 
basis-- has yielded to profitability calculations. And, in most of 
the rest, considerations of at least calculating and recovering costs 
have crept in. While many of us feel some nostalgia for the old 
system, it is clear that its days are waning if not gone: perhaps the 
public service notions as understood when 1591 was written just don’t 
scale to rapid internet growth and very large numbers of 
yregistrations. 


In particular, some ccTLDs have advertised for registrations outside 
the designated countries (or other entities), while others have made 
clear decisions to allow registrations by non-nationals. These 
decisions and others have produced protests from many sides, 
suggesting, in turn, that a recategorization is in order. For 
example, we have heard concerns by governments and managers of 
traditional, "public service", in-country, ccTLDs about excessive 
ICANN interference and fears of being forced to conform to 
internationally-set policies for dispute resolution when their 
domestic ones are considered more appropriate. We have also heard 
concerns from registrars and operators of externally-marketed ccTLDs 
about unreasonable government interference and from gTLD registrars 
and registries about unreasonable competition from aggressively 
marketed ccTLDs. The appropriate distinction is no longer between 
what RFC 1591 described as "generic" TLDs (but which were really 
intended to be "purpose-specific", a term I will use again below) and 
ccTLDs but among: 


(i) true "generic" TLDs, in which any registration is acceptable 
and, ordinarily, registrations from all sources are actively 
promoted. This list currently includes (the formerly purpose- 
specific) COM, NET, and ORG, and some ccTLDs. There have been 
proposals from time to time for additional TLDs of this variety in 
which, as with COM (and, more recently, NET and ORG) anyone 
(generally subject only to name conflicts and national law) could 
register who could pay the fees. 


(ii) purpose-specific TLDs, in which registration is accepted only 
from organizations or individuals meeting particular 
qualifications, but where those qualifications are not tied to 
national boundaries. This list currently includes INT, EDU, the 
infrastructure domain ARPA, and, arguably, the specialized US 
Government TLDs MIL and GOV. There have been proposals from time 
to time for other international TLDs of this variety, e.g., for 
medical entities such as physicians and hospitals and for museums. 
ICANN has recently approved several TLDs of this type and 
describes them as "sponsored" TLDs. 
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(iii) Country domains, operated according to the original 
underlying assumptions of 1591, i.e., registrants are largely 
expected to be people or other entities within the country. While 
external registrations might be accepted by some of these, the 
country does not aggressively advertise for such registrations, 
nor does anyone expect to derive significant fee revenue from 
them. All current domains in this category are ccTLDs, but not 
all ccTLDs are in this category. 


These categories are clearly orthogonal to the association between 
the use of the IS 3166-1 registered code list [2] and two-letter 
"country" domain names. If that relationship is to be maintained 
(and I believe it is desirable), the only inherent requirement is 
that no two-letter TLDs be created except from that list (in order to 
avoid future conflicts). ICANN should control the allocation and 
delegation of TLDs using these, and other, criteria, but only 
registered 3166-1 two letter codes should be used as two-letter TLDs. 


2. Implications of the Categories 


If we had adopted this type of three-way categorization and could 
make it work, I believe it would have presented several opportunities 
for ICANN and the community more generally to reduce controversies 
and move forward. Of course, there will be cases where the 
categorization of a particular domain and its operating style will 
not be completely clear-cut (see section 3, below). But having ICANN 
work out procedures for dealing with those (probably few) situations 
appears preferable to strategies that would tend to propel ICANN into 
areas that are beyond its competence or that might require 
significant expansion of its mandate. 


First, the internally-operated ccTLDs (category iii above) should not 
be required to have much interaction with ICANN or vice versa. Once 
a domain of this sort is established and delegated, and assuming that 
the "admin contact in the country" rule is strictly observed, the 
domain should be able to function effectively without ICANN 
intervention or oversight. In particular, while a country might 
choose to adopt the general ICANN policies about dispute resolution 
or name management, issues that arise in these areas might equally 
well be dealt with exclusively under applicable national laws. If a 
domain chooses to use ICANN services that cost resources to provide, 
it should contribute to ICANN’s support, but, if it does not, ICANN 
should not presume to charge it for other than a reasonable fraction 
of the costs to ICANN of operating the root, root servers, and any 
directory systems that are generally agreed upon to be necessary and 
in which the domain participates. 
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By contrast, ccTLDs operated as generic domains ought to be treated 
as generic domains. ICANN dispute resolution and name management 
policies and any special rules developed to protect the Internet 
public in multiple registrar or registry situations should reasonably 
apply. 


3. Telling TLD types apart 


If appropriate policies are adopted, ccTLDs operated as generic 
domains (category (i) above) and those operated as country domains 
(category (iii) above) ought to be able to be self-identified. There 
are several criteria that could be applied to make this 
determination. For example, either a domain is aggressively seeking 
outside registrations or it is not and either the vast majority of 
registrants in a domain are in-country or they are not. One could 
also think of this as the issue of having some tangible level of 
presence in the jurisdiction - e.g., is the administrative contact 
subject, in practical terms, to the in-country laws, or are the 
registration rules such that it is reasonably likely that a court in 
the jurisdiction of the country associated with the domain can 
exercise jurisdiction and enforce a judgment against the registrant. 


One (fairly non-intrusive) rule ICANN might well impose on all top- 
level domains is that they identify and publish the policies they 
intend to use. E.g., registrants in a domain that will use the laws 
of one particular country to resolve disputes should have a 
reasonable opportunity to understand those policies prior to 
registration and to make other arrangements (e.g., to register 
elsewhere) if that mechanism for dispute resolution is not 
acceptable. Giving IANA (as the root registrar) incorrect 
information about the purpose and use of a domain should be subject 
to challenge, and should be grounds for reviewing the appropriateness 
of the domain delegation, just as not acting consistently and 
equitably provides such grounds under the original provisions of RFC 
1591. 


In order to ensure the availability of accurate and up-to-date 
registration information the criteria must be consistent, and 
consistent with more traditional gTLDs, for all nominally country 
code domains operating as generic TLDs. 


4. The role of ICANN in country domains 
ICANN (and IANA) should, as described above, have as little 


involvement as possible in the direction of true country [code] 
domains (i.e., category (iii)). There is no particular reason why 
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these domains should be subject to ICANN regulation beyond the basic 
principles of 1591 and associated arrangements needed to ensure 
Internet interoperability and stability. 


ICANN’s avoiding such involvement strengthens it: the desirability of 
avoiding collisions with national sovereignty, determinations about 
government legitimacy, and the authority of someone purportedly 
writing on behalf of a government, is as important today as it was 
when 1591 was written. The alternatives take us quickly from 
"administration" into "internet governance" or, in the case of 
determining which claimant is the legitimate government of a country, 
"international relations", and the reasons for not moving in that 
particular direction are legion. 


5. The role of governments 


The history of IANA strategy in handling ccTLDs included three major 
"things to avoid" considerations: 


* Never get involved in determining which entities were countries 
and which ones were not. 


* Never get involved in determining who was, or was not, the 
legitimate government of a country. And, more generally, avoid 
deciding what entity --government, religion, commercial, 
academic, etc.-- has what legitimacy or rights. 


* If possible, never become involved in in-country disputes. 
Instead, very strongly encourage internal parties to work 
problems out among themselves. At most, adopt a role as 
mediator and educator, rather than judge, unless abuses are very 
clear and clearly will not be settled by any internal mechanism. 


All three considerations were obviously intended to avoid IANA’s 
being dragged into a political morass in which it had (and, I 
suggest, has) no competence to resolve the issues and could only get 
bogged down. The first consideration was the most visible (and the 
easiest) and was implemented by strict and careful adherence (see 
below) to the ISO 3166 registered Country Code list. If an entity 
had a code, it was eligible to be registered with a TLD (although 
IANA was free to apply additional criteria-most of them stated in 
1591). If it did not, there were no exceptions: the applicant’s only 
recourse was a discussion with the 3166 Registration Authority (now 
Maintenance Agency, often known just as "3166/MA") or the UN 
Statistical Office (now Statistics Bureau), not with IANA. 
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There are actually five ccTLD exceptions to the strict rules. One, 
"UK", is historical: it predates the adoption of ISO 3166 for this 
purpose. The others --Ascension Island, Guernsey, Isle of Man, and 


Jersey --are arguably, at least in retrospect, just mistakes. 
Regardless of the historical reasons (about which there has been much 
speculation), it is almost certainly the case that the right way to 
handle mistakes of this sort is to acknowledge them and move on, 
rather than trying to use them as precedents to justify more 
mistakes. 


This, obviously, is also the argument against use of the "reserved" 
list (technically internal to the 3166 maintenance activity, and not 
part of the Standard): since IANA (or ICANN) can ask that a name be 
placed on that list, there is no rule of an absolute determination by 
an external organization. Purported countries can come to ICANN, 
insist on having delegations made and persuade ICANN to ask that the 
names be reserved. Then, since the reserved name would exist, they 
could insist that the domain be delegated. Worse, someone could use 
another organization to request reservation of the name by 3166/MA; 
once it was reserved, ICANN might be hard-pressed not to do the 
delegation. Of course, ICANN could (and probably would be forced to) 
adopt additional criteria other than appearance on the "reserved 
list" in order to delegate such domains. But those criteria would 
almost certainly be nearly equivalent to determining which applicants 
were legitimate and stable enough to be considered a country, the 
exact decision process that 1591 strove to avoid. 


The other two considerations were more subtle and not always 
successful: from time to time, both before and after the formal 
policy shifted toward "governments could have their way", IANA 
received letters from people purporting to be competent government 
authorities asking for changes. Some of them turned out later to not 
have that authority or appropriate qualifications. The assumption of 
1591 itself was that, if the "administrative contact in country" rule 
was strictly observed, as was the rule that delegation changes 
requested by the administrative contact would be honored, then, if a 
government _really_ wanted to assert itself, it could pressure the 
administrative contact into requesting the changes it wanted, using 
whatever would pass for due process in that country. And the ability 
to apply that process and pressure would effectively determine who 
was the government and who wasn’t, and would do so far more 
effectively than any IANA evaluation of, e.g., whether the letterhead 
on a request looked authentic (and far more safely for ICANN than 
asking the opinion of any particular other government or selection of 
governments). 
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Specific language in 1591 permitted IANA to adopt a "work it out 
yourselves; if we have to decide, we will strive for a solution that 
is not satisfactory to any party" stance. That approach was used 
successfully, along with large doses of education, on many occasions 
over the years, to avoid IANA’s having to assume the role of judge 
between conflicting parties. 


Similar principles could be applied to the boundary between country- 
code-based generic TLDs and country domains. Different countries, 
under different circumstances, might prefer to operate the ccTLD 
either as a national service or as a profit center where the 
"customers" were largely external. Whatever decisions were made 
historically, general Internet stability argues that changes should 
not be made lightly. At the same time, if a government wishes to 
make a change, the best mechanism for doing so is not to involve 
ICANN in a potential determination of legitimacy (or even to have 
ICANN’s Government Advisory Committee (GAC) try to formally make that 
decision for individual countries) but for the relevant government to 
use its own procedures to persuade the administrative contact to 
request the change and for IANA to promptly and efficiently carry out 
requests made by administrative contacts. 


6. Implications for the current ICANN DNSO structure. 


The arguments by some of the ccTLD administrators that they are 
different from the rest of the ICANN and DNSO structures are (in this 
model) correct: they are different. The ccTLDs that are operating as 
generic TLDs should be separated from the ccTLD constituency and 
joined to the gTLD constituency. The country ccTLDs should be 
separated from ICANN’s immediate Supporting Organization structure, 
and operate in a parallel and advisory capacity to ICANN, similar to 
the arrangements used with the GAC. The DNSO and country TLDs should 
not be required to interact with each other except on a mutually 
voluntary basis and, if ICANN needs interaction or advice from some 
of all of those TLDs, it would be more appropriate to get it in the 
form of an advisory body like the GAC rather than as DNSO 
constituency. 
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